Date: Thu, 9 Dec 93 04:30:31 PST 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V93 #141 

To: Ham-Digital 


Ham-Digital Digest Thu, 9 Dec 93 Volume 93 : Issue 141 


Today's Topics: 
ATM on Amateur Radio? 
Digital with Sound Blaster??? 
F6FBB release 5.15b ? 
How much time does a G3RUH modem take to acquire signal? 
Looking for NOS Executable with NNTP 
Need advice on using tube-final rigs for RTTY/AFSK 
TEKK Radios 
Understanding AX.25 Packet monitored frames 
W9GR DSP article of Sept 1992 QST 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Mon, 6 Dec 1993 20:35:10 GMT 

From: nntp.ucsb.edu!library.ucla.edu!europa.eng.gtefsd.com!howland.reston.ans.net! 
vixen.cso.uiuc.edu!newsrelay.iastate.edu!news.iastate.edu! 

metropolis. gis.iastate.edu!willmore@network.ucsd.edu 

Subject: ATM on Amateur Radio? 

To: ham-digital@ucsd.edu 


karn@unix.ka9q.ampr.org (Phil Karn) writes: 

>OSYSMAS@MVS.OAC.UCLA.EDU (Michael Stein) writes: 

>|> ATM breaks packets up into cells, the idea being that an time 

>|> critical (voice or video) packet can't affort to be held back 

>|> because a long (4k bytes?) packet is being sent. So all packets 
>|> are broken into cells, which can then be sent as needed (critical 
>|> ones first). 


>|> 

>|> Well, it appears that this solves the problem. Only on a 1Gbit 
>|> link a 4K byte packets is only 32 microseconds long so the 

>|> problem doesn't really exist for this speed link! 


>Absolutely! But you must understand the real driving factor behind the 
>design of ATM: voice. For all their lip service of "integrated" 
>voice/data/video services and supporting the Information Age, voice is 
>still the telcos' bread and butter, and it's the only thing they 
>consider important. For example, the specific frame size chosen for 
>ATM (48 bytes of data + 5 bytes of header) was picked to minimize the 
>packetizing delay for conventional 64kb/s digital voice, so as to 
>avoid having to use echo cancellers to take care of reflections off of 
>the hybrids in the analog local loops at the ends of a voice 

>call. (The degree to which people object to an echo of a given 
>amplitude is a strong function of its delay -- the longer the delay, 
>the more annoying it is). To be sure, this choice was more the fault 
>of the Europeans than the Americans, who wanted a somewhat larger cell 
>size. 


Date: Tue, 7 Dec 1993 15:41:48 GMT 

From: usc!howland.reston.ans.net! pipex!bnr.co.uk!corpgate!nrtpa038!b4pphi3e! 
cnc23a@network.ucsd.edu 

Subject: Digital with Sound Blaster??? 

To: ham-digital@ucsd.edu 


In your previous article, you wrote: 


Can someone please tell me if there is any software that uses a Sound 
Blaster to receive CW,RTTY,SSTV,PACKET,etc,etc. 


Thanks, 73, 

Scott R. Weis KB2EAR 

Internet: kb2ear@kb2ear.ampr.org 

Snail Mail: 10 Palmer Rd., Kendall Park, NJ, 08824-1228 
Phone: +1 908 297 0469 


VV VV VV VV WV 


I'm sorry for not e-mailing, but my mail sys is funny. 
For CW : FFTMORSE by Francois Jalbert (jalbert@IRO.UMontreal.CA) 
For SSTV: SLOWSC by Gene Harlan WB9MMM 


For DTMF: _DMTF by Peter Jennings VE3SUN 


I found these on my SIMTEL CD, 
a local ham has developed a RTTY program, but has not generally released it. 


PACKET ???? 


Hope this is of some help. 


73s es CUL N4ZBB 


Ken M. Edwards, PE Bell Northern Research, Research Triangle Park, NC 
(919) 481-8476 email: cnc23a@bnr.ca Ham: N4ZBB 


All opinions are my own and do not necessarily reflect the views of 
my employer or co-workers, family, friends, congress, or president. 


(To the e-mail'r out there -> This is a short as it will gets) 


Date: 9 Dec 93 11:03:29 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: F6FBB release 5.15b ? 
To: ham-digital@ucsd.edu 


Can someone please tell me if is available the new release 5.15b of the 
F6FBB bbs software ? If so, where can be ftp'ed ? 
Tks, 73, 


Luiz Catalan 
internet: catalan@vortex.ufrgs.br 
packet: pp5aq@pp5aq.bra.sa 


Date: 9 Dec 93 06:41:00 GMT 

From: news-mail-gateway@ucsd.edu 

Subject: How much time does a G3RUH modem take to acquire signal? 
To: ham-digital@ucsd.edu 


When a 9600 baud modem of the G3RUH/K9NG-type hears a signal, how long 
does it take (or more accurately, how many bit periods) does it take to 
begin to properly decode data? 


If it is just a matter of getting a few bit periods to sync the state machine, 
and then, say, 17 more to get the descrambler working, then 20 milliseconds 
should be more than enough time to get things working. 


In practical experience, how long xdoesx it take for the modem to start 
decoding data properly (at 9600 baud?) 


Thanks, 


<Clint> 


Date: Fri, 3 Dec 1993 15:10:22 GMT 

From: agate! howland.reston.ans.net!EU.net!sun4nl!hacktic!utopia.hacktic.nl1! 
globv1.hacktic.nl!peter@ames.arpa 

Subject: Looking for NOS Executable with NNTP 

To: ham-digital@ucsd.edu 


ron@alpha.nsula.edu (Ron Wright) writes: 


>I am looking for a compiled version of NOS that has the NNTP server compiled 
>in. I do not currently have a compiler so I can't put together my own. Along 
>these lines... 


WNOS has nntp support built in. It's on ucsd.edu:/hamradio/packet/tcpip/wnos. 


>Does anyone know of the GNU c++ compiler will successfully 
>compile NOS. 


You mean DJGPP, the GCC compiler for MS-DOS? If so, then the answer is no. 


Groetjes, 
Peter Busser 


Linux, the choice of a GNU generation. 


Date: 7 Dec 1993 13:07:29 +0200 

From: ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!EU.net!news.funet.£i! 
klaava!klaava!not-for-mail@network.ucsd.edu 

Subject: Need advice on using tube-final rigs for RTTY/AFSK 

To: ham-digital@ucsd.edu 


I'll be shopping for a used rig soon and will be on a very tight 
budget, so I'm trying to get a picture of what the minimal rig would be 
that will do what I want. Other than SSB/CW, I've been itching to get 
into RTTY, but have heard that many older rigs have problems both from 
the 100% duty cycle and sluggish operation. 


I'm intrested in hearing people's experiences working the various 
digital modes on HF using older tube rigs, or rigs with tube finals. 
More than likely, I'll be using a late-model multimode TNC and AFSK for 
HF RTTY/Baudot/AMTOR. What sort of things should I look for ina 
suitable rig. Obviously, the quality of the SSB signal is more 
important when using AFSK rather than FSK (right?). How can one 
estimate the max. drive the finals can take at 100% duty cycle? How 

can one determine if the tx is "fast" enough (or is sluggishness 

only a problem with FSK and not AFSK?). 


Of course, I'd particularly appreciate any recommendations for (or 
against) particular rigs, which would help me in my shopping. 


Thanks, 


PLTATTAAATAA AAA ATTA TAA AAT ATI AT AA PATS PATA TA AAT AT 
Patrick M. Stickler OH2LUV, KC4YYY The comments contained herein 
WSOY - Information Systems Division do not necessarily reflect the 
Helsinki, FINLAND (psti@wsoy. fi) official views of my employer. 

ITTLTTATATTATA TATA TAS ATTA AAT AT AAT AT AA TAA TAAL TATA TAA AA AAT LT 


Date: Tue, 7 Dec 1993 02:45:12 GMT 

From: netcomsv!netcom.com! fmitch@decwrl.dec.com 
Subject: TEKK Radios 

To: ham-digital@ucsd.edu 


tekk has a special on the little data radios until the end of the 
year... call them for details... 800-521-8355... 


mitch, wa4osr 


fmitch@netcom.com 

Felton "Mitch" Mitchell, WA40SR in Mobile, Alabama USA 

205-342-7259 home, 205-476-4100 work, 205-476-0465 FAX 

co-sysop for W4IAX bbs running fbb ... sysop for WA4OSR DxXCluster in Mobile.. 


Date: 8 Dec 93 16:25:28 GMT 

From: news-mail-gateway@ucsd.edu 

Subject: Understanding AX.25 Packet monitored frames 
To: ham-digital@ucsd.edu 


UNDERSTANDING MONITORED PACKET FRAMES 
Don Rotolo N2IRZ 
Have you ever monitored the packet channel and wondered just what all those 


letters and numbers at the beginning of each packet "frame" mean ? Well, 
wonder no more ! This article will explain the basics of packet control. 


All packet HDLC (High-level Data Link Control) frames are similar, consisting 
of 6 unique "fields": 


| Flag | Address | Control | PID & Data | FCS | Flag | 


FLAG : The Flag fields are put at the beginning and end of each frame to 
indicate the boundaries of the frame. A unique bit sequence is used 
(01111110) so other parts of the frame won't be mistaken for a Flag. 


ADDRESS: This field normally specifies the destination of the frame. This is 
the actual call signs of the source, destination, and any digipeaters. 


CONTROL: This field identifies the frame type. See FRAME TYPES below. 


PID: The first byte of the Data field is the Protocol ID, specifying the 
type of protocol in use. 


DATA: This is the actual data to be transferred. Many frames do not have a 
data field. 


FCS: Frame Check Sequence, this is how errors are detected in a frame. Your 
TNC creates a number based on the rest of the fields, using a special 
mathematical formula. The other TNC does the same, and if the numbers 
match, the frame has no errors and is accepted. 


We will examine a typical frame: 
KD6TH-4>N2DSY-2*>N2IRZ [1;3,1]:0042z, 838 msgs, #40407 last @KD6TH-4 Mailbox> 
<----Address--------- > <----- > <rnrrrrccne Data----------- 5-5-2 r rrr rrr eee > 


Control 


Note that you do not see the Flag, PID and FCS fields. 


FRAME TYPES: 


C Connect frame. Also known as a 'SABM' frame (Set Asynchronous Balanced 
Mode). 

D Disconnect frame. 

DM Disconnect Mode frame. 

I Information frame. 

UA Unnumbered Acknowledgement frame. 

UI Unnumbered Information frame. 

RR Receive Ready command and response. 


RJ ReJect frame. 

RNR Receive Not Ready command and response. 
FRMR FRaMe Reject response. 

DM Disconnected Mode response. 


When you type into your TNC a connect command, the TNC generates a frame like: 
N2TRZ*>KD6TH-4 [C,P] 


This means that N2IRZ is trying to connect to KD6TH-4. The * shows who is 
transmitting. The > shows the direction the frame is going (to KD6TH-4). The 
"C" indicates that it is a Connect frame, and the "P" means that the "Poll" 
bit is set. When the Poll bit is set, it means the originating station is 
Polling (or "searching") for the destination station (sort of asking "are you 
there ??"). I the destination station was to respond, it would send an "F", 
or Final, bit in response ("yep, I'm here"). If the radio path is "perfect", 
the Poll/Final bits will rarely be used again. 


KD6TH-4 is able to establish a connection to N2IRZ, so it sends: 
KD6TH-4*>N2IRZ [UA,F] 


This means that KD6TH-4 has acknowledged receiving N2IRZ's Connect request, 
and confirms the connection. Your TNC generates the familiar "xxx Connected to 
" message for you. KD6TH-4 now sends a greeting (his "Connect Text"): 


KD6TH-4*>N2IRZ [1I,P;0,0]:Hi Don, Welcome to KD6TH-4 BBS ! 


The "I" tells us that this is an information frame. The information (Hi 
Don...) can be any text. P is for Polling - KD6TH-4 is just making sure N2IRZ 
is still there. What is interesting here are the numbers in the "[I,P;0,0]:" 
part: The first number is the next frame number that KD6TH-4 expects from 
N2IRZ, and the second number is the number of the frame that is being sent. 
The order of the numbers switches when N2IRZ is sending. Upon receiving this 
frame without errors, N2IRZ sends: 


N2TRZ*>KD6TH-4 [RR,F;1] 


Telling KD6TH-4 that N2IRZ got frame 0 OK and is ready to receive frame 1. 
KD6TH-4 sends 2 more info frames to N2IRZ: 


KD6TH-4*>N2IRZ [1;0,1]:*** You have Unread Mail !!! 
KD6TH-4*>N2IRZ [1I;0,2]:0045z, 745 msgs, #40498 last @KD6TH-4 Mailbox> 


N2IRZ didn't get the First packet without errors, but did get the Second, so 
it sends: 


N2IRZ*>KD6TH-4 [RIJ;1] 

Which tells KD6TH-4 that it is rejecting the received packet: N2IRZ still 
wants packet number 1. If both packets were received OK, N2IRZ would simply 
send [RR;3] and the process would continue, but if N2IRZ hadn't received 
EITHER packet, no response would have been sent. Then KD6TH-4 would have 
started polling: 

KD6TH-4*>N2IRZ [RR,P;0] 

N2IRZ would reply 

N2IRZ*>KD6TH-4 [RR,F;1] 

Eventually, N2IRZ is finished reading the mail, so he signs off: 
N2IRZ*>KD6TH-4 [1;5,2]:Bye 


This is N2IRZ's frame 2, and he expects frame 5 back. KD6TH-4 responds 


KD6TH-4*>N2IRZ [RR;3] 
KD6TH-4x>N2IRZ [D,P] 


First the "Bye" packet is acknowledged, and then KD6TH-4 initiates a 
disconnect. N2IRZ responds 


N2IRZ*>KD6TH-4 [UA,F] 

and they are disconnected. KD6TH-4 now sends out its "MAIL_FOR:" beacon: 
KD6TH-4*>BBS [UI]: Mail_for: N2DSY WA2SQQ KA2USU W5GZT KB2BAV WA2SPO 

This last frame is an Unnumbered Information frame. The place it is addressed 
to (in this case, "BBS") is specified by the UNproto command, which usually 


has the default of "CQ". 


Now you have a good idea of what C, UA, I, RR, RJ, D and UI frames are like. 
A DM frame is sent when the other station is busy, or CONOk is Off, and your 


TNC generates a message that "KD6TH-4 is Busy", while KD6TH-4's TNC generates 
a "xxx Connect Request: N2IRZ" message. 

The other frame types are somewhat rare: RNR is sent when one station polls 
another ("are you there ?") but the other station isn't ready to process 
another packet yet. FRMR is only sent when all hell breaks loose: the Frame 
Type (I, UA, RR, etc) is either undefined or improper protocol (Wrong type of 
reply). 


If you would like to learn more about the AX.25 Protocol, or Packet Radio in 
general, I suggest the following: 


Terry Fox, "AX.25 Amateur Packet Radio, Link-Layer Protocol Version 2.0", 
(Available from the ARRL), October 1984. 


Jim Grubbs, "Get ***xCONNECTED to Packet Radio", QSKY Publishing, Springfield, 
Illinois. 1986. (Easy to read, great bibliography) 


Max Adams, "Basic Amateur Radio Packet", CQ Magazine, November 1985, pp.13-20. 


This article is part of an informal series of technical articles intended to 
promote experimentation, good operating habits, safety and technical 
knowledge. This article may be copied freely, with proper acknowledgement. 
Feedback is welcomed. 


KKKKKKKKKEKSEK 
73 de Don Rotolo 


* KKK KKK KEK KKK KKK KEK KKK 
* 

* N2TRZ@kd6th.nj.usa 

* 

* 


Knowledge is the only instrument 
of production that is not subject 
to diminishing returns -J.M. Clark 
ee es 


CIS : 73227,2644 
KKK KKK KK KKK 


+ + OF 
+ + OF 


Date: Tue, 7 Dec 1993 18:45:51 GMT 

From: news.kpc.com!kpc!nat@decwrl.dec.com 
Subject: W9GR DSP article of Sept 1992 QST 
To: ham-digital@ucsd.edu 


Hi, 
I just stumbled across W9GR's article and am itching to build it. 
I have several questions: 
1. is the PC board available. I can get hold of the parts locally. 
2. The article mentions that the TI assembly files for the prom code 
are available on compuserve. Are they also available at some internet ftp site. 
Any pointers would be helpful. 
3. The article also mentions that the prom programming files are 
also available. Again pointers would be helpful. 


Thanks in advance. 
Nat. 


Natarajan Gurumoorthy AB6SJ Kubota Pacific Computer, Inc. 
nat@kpc.com 2630 Walsh Avenue 
Phone 408 987 3341 Santa Clara, California 95051. 


Date: (null) 

From: (null) 

>Nevertheless, complaints from computer networking people that tiny, 
>fixed-sized cells were not what they needed didn't seem to faze the 
>telcos. 


ATM just requires a protocol encapsulation/translation. Nothing much worse 
than fragments in TCP/IP. 


>|> Also my understanding is that currently all you can get today on 
>|> ATM is a permanent virtual circuit, no "dial up". It appears 
>|> that switched service is years away. And it's not clear how 

>|> (if?) ATM will handle multicast traffic. 


>A very common misconception about ATM, perhaps encouraged by the 
>telcos themselves to sound more trendy, is that ATM is packet 
>switching. It really isn't. First of all, ATM cells look nothing 
>like, say, the Ethernet frames with which computer networking people 
>are familiar: full source and destination addresses, followed by a 
>variable length data field with a reasonably large size limit. And 
>there's too little buffering in an ATM switch to make it a true packet 
>network, where lots of little bursty users all contend for each link 
>through a queue. 


The first time a packet follows a path through any modern routing system, 
the router will have to take extra time to compute the destination. Once 
it has cached that address resolution, latter packets take less time to 
route. Why should ATM be any different? Sure, it makes a packet switched 
network look more like a virtual circuit network, but that's just reality. 
Most packets go where one has already gone, anyway. 


>So to achieve a reasonably low lost-cell rate in ATM, you have to set 
>up a circuit in advance and preallocate some fraction of link 
>bandwidth. If it isn't used, it goes to waste. Think of ATM as just 
>another TDM (time division multiplex) switch, albeit with somewhat 
>finer-grained control over the bandwidth allocations that can be 
>made. Other than that, ATM doesn't do much that can't already be done 


>by a much simpler cross-connect switch at far lower cost. 


ATM would mostly be used to connect together LAN's into larger collections. 
With that in consideration, why wouldn't the traffic be fairly steady 
between nodes? It's not like ATM was supposed to run to peoples houses 
directly. 


>|> Remember, ATM is brought to you by the same people who designed 
>|> ISDN as the answer to local telephone service. Will it follow 
>|> the same installation / availability / cost path? 


>Most likely, or even worse. ISDN's and ATM's "features" are worse than 
>useless to anyone trying to build a real packet switched network like 
>the Internet. Oh sure, you *xcanx use them, and people do when the 
>tariffs are right. But all that added complexity buys you nothing over 
>a bunch of leased lines. Hence they're worse than useless. 


>In the case of ISDN, I don't know anyone who uses it as anything but a 
>leased line substitute between local packet routers. And this happens 
>only when the telcos price ISDN far enough below their traditionally 
>overpriced leased line services to make it worth dealing with ISDN's 
>many added hassles. Of course, if the telcos were to price all their 
>services according to their true costs, ISDN would immediately 
>disappear and they'd have to admit their mistake. 


ISDN didn't work out because it took so long to get some switches upgraded. 

This brought broadband ISDN closes and caused some of the market demand to 
decide to wait for B-ISDN. xsigh* Things like that happen. Remember Floptical 
Drives? They took too long to get to get to market that other technology 

like 128Meg MO drives and 140Meg MD drives beat them out. 


>Raw digital transmission, at least along major fiber routes, is the 
>one thing the telcos know how to do well. Unfortunately, getting just 
>that service out of them at a reasonable price is very difficult. Raw 
>transmission isn't "glamorous" enough for the telcos, so they keep 
>trying to "do it all" (e.g., move into information 

>services). Unfortunately, they don't even know how to properly 
>xswitch*x data, much less provide the complete stack including the 
>applications. 


With this, I can agree. All I want is a T1 line... xsighx 


>|> What does this have to do with Amateur Radio? Well, I've been 
>|> thinking about all the claims that there isn't enough spectrum to 
>|> do Gigabit networking via RF. Really? What about local and line 
>|> o£ sight links in the 24Ghz to 100Ghz range? Sounds hard (a 

>|> challange) today, but doesn't sounds like it will remain so... 


>Well, IF we were to use ATM, then those claims about insufficient 
>spectrum would be true. If we don't, there shouldn't be a problem. :-) 


Good dig, but I'm not convinced that ATM is the best for radio use. Let 
me rephrase that. ATM is very poor for radio use. One of the prime 
assumptions of ATM was that the physical carrier had a very low bit error 
rate. Radio doesn't exactly meet that specification. 


Cheers, 
David (NOYMV) 


willmore@iastate.edu | "Death before dishonor" | "Better dead than greek" | 
David Willmore | "Ever noticed how much they look like orchids? Lovely!" | 


End of Ham-Digital Digest V93 #141 
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